Cached data repurposing

ABSTRACT

The described technology is directed towards repurposing expired cached data when no unexpired data is available. Cached, unexpired data is used in response to a request when such data exists. If such data does not exist, e.g., at a front-end data service, then an attempt to obtain the requested data from another (e.g., back-end data service) is made. If the attempt is unsuccessful, and expired cached data exists, the expired cached data is returned in response to the request, e.g., instead of returning an error. A back-end data service may similarly return expired cached data when the back-end data service is unable to obtain unexpired requested data elsewhere. An emergency mode may be entered in which data, whether expired or not, is returned from a cache when such data exists, such as when an attempt to obtain the data elsewhere is known in advance to be futile.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of co-pending U.S. patent applicationSer. No. 15/167,288 filed May 27, 2016, entitled “CACHED DATAREPURPOSING.” The entirety of the aforementioned application is herebyincorporated by reference herein.

BACKGROUND

Conventional data caches provide a fast way to access data. One typicaltype of cache uses a hash function related to a request for data todetermine a cache location corresponding to the requested data, whichfacilitates constant time lookup. If the requested data is found in thecache, the data is returned from the cache. If not, (that is, there is acache miss), the data is retrieved from another source (e.g., a physicaldata store), returned in response to the request and written into thecache at the appropriate location.

Each data entry in the cache is typically associated with an expirationvalue, such as a time-to-live or timestamp value. When a request forcached data is received but the data is determined to be expired, theexpired data is typically treated as a cache miss, resulting inreturning the data from the other source and updating the cache entrywith the non-expired data and a new expiration value. At times there areproblems with obtaining the data from the other source, however.

SUMMARY

This Summary is provided to introduce a selection of representativeconcepts in a simplified form that are further described below in theDetailed Description. This Summary is not intended to identify keyfeatures or essential features of the claimed subject matter, nor is itintended to be used in any way that would limit the scope of the claimedsubject matter.

Briefly, the technology described herein is directed towards usingexpired cached data when such expired cached data exists and nounexpired data is otherwise available. Upon receiving a client requestfor client-requested data, a cache set (one or more caches) is accessedto attempt to locate the client-requested data. If the data is in thecache set and is not expired data, the data is returned from the cacheset in response to the client request. If the data is in the cache setand is expired data, the expired data is maintained and the data isrequested from a data provider. If the requested data is available fromthe data provider, the data is received from the data provider and isreturned in response to the client request. If the data is not availablefrom the data provider, the expired data is returned in response to theclient request

Other advantages may become apparent from the following detaileddescription when taken in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The technology described herein is illustrated by way of example and notlimited in the accompanying figures in which like reference numeralsindicate similar elements and in which:

FIG. 1 is a block diagram representing example components that handlerequests for data including via caches with possibly expired data,according to one or more example implementations.

FIG. 2 is a block diagram representing example components of a front-endrequest handling server that may return repurposed (expired) data in aresponse to a request when no unexpired data is available, according toone or more example implementations.

FIG. 3 is a block diagram representing example components of a back-endbrowse data service server that may return repurposed data in a responseto a request when no unexpired data is available, according to one ormore example implementations.

FIGS. 4 and 5 are block diagrams representing example components ofbatch request managers, one of a front-end server (FIG. 4 ) and anotherof a back-end server (FIG. 5 ) that each may batch and/or multiplexrequests for data, according to one or more example implementations.

FIG. 6 is a representation of batching and multiplexing data requests(and demultiplexing responses), according to one or more exampleimplementations.

FIGS. 7 and 8 comprise a flow diagram showing example logic/steps thatmay be performed to return data in response to a request, includingrepurposed data when unexpired data is not available, according to oneor more example implementations.

FIGS. 9 and 10 comprise a flow diagram showing example logic/steps thatmay be performed to return data in response to a request from a frontend service, including repurposed data when unexpired data is notavailable, according to one or more example implementations.

FIG. 11 is a block diagram representing an example computing environmentinto which aspects of the subject matter described herein may beincorporated.

DETAILED DESCRIPTION

Various aspects of the technology described herein are generallydirected towards reusing data that is expired when no fresher data isobtainable. In general, the technology operates to avoid returning anerror in response to a client request when possible. To this end, one ormore aspects are directed towards returning stale data in response to arequest rather than an error, such as when an attempt to obtain fresherdata fails or is taking an undesirable amount of time. As used herein,requested data is not “available” when a request seeking that data timesout (which may or may not be an actual error) and/or fails because ofany other error.

In one or more aspects, stale data is not discarded but returned to arequesting entity, typically along with some indication that the data isstale. This may be a conventional timestamp or time-to-live (TTL) valuealready associated with the cached data, or some other flag. Therequesting entity may then attempt to obtain the data from anothersource, such as another service, physical database or the like. If thisattempt fails or takes too long, the requesting entity may return thestale data to the client in response to the original request. As can bereadily appreciated, this provides for satisfying client requests inscenarios where stale data is acceptable to an extent, rather thanreturning errors or taking so long that the client user gets frustrated.

By way of example, consider a client device that is requesting a user'swatch-list, comprising a set of items representing television contentthat the user has specifically identified as desirable for viewing.Items on a watch-list expire, such as when a show on that watch-list isno longer offered to be viewed (e.g., a show may only be offered forviewing for a limited period of time). It is also feasible that a showmay be automatically added to a user's watch-list. In the event that thenew watch-list cannot be built from a data service servers/databases,such as when a database is down, an expired watch-list from a cache maybe returned to the user. Although this watch-list may not accuratelyreflect what is currently viewable, it is likely preferable to the userto view a somewhat outdated watch-list than to instead receive an errormessage when requesting his or her watch-list; often, the user may notnotice.

Similarly, receiving an outdated watch-list with some expired content islikely more desirable to users than to have to wait several seconds foran updated one. For example, a user may want to watch a show that iscurrently available for viewing and not even notice that a show appearsthat is not currently being offered for viewing (actually expired),whereby waiting too long is undesirable and unnecessary. Although thereis no way to know what a particular user would prefer to do, a maximumacceptable wait time may be estimated (e.g., empirically determined) forall or most users, or may be user configurable.

It should be understood that any of the examples herein arenon-limiting. For instance, some of the examples refer to returningprogram-related catalog items, such as built from various data sourcesto represent television content such as movies or shows. However, thetechnology described herein is independent of any particular type ofdata being cached. As another example, certain efficiency enhancementsare exemplified, such as those related to reducing the total amount ofnetwork traffic, but these are only optimizations, not requirements. Assuch, the technology described herein is not limited to any particularembodiments, aspects, concepts, structures, functionalities or examplesdescribed herein. Rather, any of the embodiments, aspects, concepts,structures, functionalities or examples described herein arenon-limiting, and the technology may be used in various ways thatprovide benefits and advantages in computing and data usage in general.

FIG. 1 is a block diagram representing example components that may beused to provide and work in conjunction with repurposed cached data asdescribed herein. In FIG. 1 , client requests 102 are received at a dataretrieval service 104, e.g., a front-end client facing service. One suchdata retrieval service 104 comprises a cluster of generallyload-balanced server machines 106(1)-106(m), where m represents anypractical number of server (virtual and/or physical) machines. In one ormore implementations, the load-balanced server machines 106(1)-106(m)each have an in memory cache, C1(1)-C1(m), respectively.

Also shown in FIG. 1 is a distributed cache 108, e.g., a REDIS cacheshared among the request handling servers 106(1)-106(m). In a typicalimplementation, the distributed cache 108 is larger than the individualin-memory caches C1(1)-C1(m) and has a higher hit rate; however thedistributed cache 108 takes longer to access, e.g., needing a networkrequest and response.

Further shown in FIG. 1 is a browse data service 110, (e.g., a back-endservice) in conjunction with one or more backing data sources 116. Inone or more implementations, the browse data service 110 similarlycomprises a cluster of generally load-balanced server machines112(1)-112(n), where n represents any practical number of such server(virtual and/or physical) machines. In one or more implementations, theload-balanced browse data server machines 112(1)-112(m) each have an inmemory cache C1(b 1)-C1(bn), respectively (where b stands for browse orback-end to differentiate these caches from those memory cachesC1(1)-C1(m) of the request handling servers). A distributed cache 114likewise is typically provided.

As used herein, the term “cache set” refers to one or more caches withina data service. If there are two or more caches in the cache set, thecaches may be arranged in a tiered configuration, with the lowest-levelcache (e.g., a server's in-memory cache) accessed first to attempt tolocate data; if not found, the next lowest-level cache is accessed nextto attempt to locate the data, and so on, up to the highest-level cacheuntil the data is found or no caches remain. Thus, in the example ofFIG. 1 , the cache set of the data retrieval server 104, from theperspective of any given request handling server (e.g., the server106(1)), comprises the lowest-level cache (e.g., in-memory cache C1(1))that server can access, and the distributed cache 108. In the example ofFIG. 1 , the cache set of the browse data service 110, from theperspective of any given request handling server (e.g., the server112(2)), comprises the lowest-level cache (e.g., in-memory cache C1(b2)) that server can access and the distributed cache 114. Any practicalnumber of caches may be in a given server's cache set, and the numbermay be different among services, as well as among different servers ofthe same service (e.g., one service's server may have two or morein-memory caches, another server of that service a single in-memorycache, and both also may share a distributed cache of the servers'service, and so on).

As described herein, even with various layers of caching, a clientrequest sometimes results in a cache miss or a cache hit of expireddata. When this occurs at the request handling server level, the requesthandling server knows that it needs to build the data, e.g., a data itemset of one or more data items, whereby the browse service 110 isinvoked. If the browse data service 110 likewise does not have a freshcopy of the requested data in a cache, the browse data service 110 makesrequests to the backing data source(s) 116 to obtain the data.

At times, however, such requests to backing data sources fail or take anunacceptable time to complete. In such situations, cached datarepurposing logic, operating at either the request handling server leveland/or the browse data service level, can return stale data instead ofan error or waiting. In any event, the clients get some appropriateresponses 118 to the requests 102.

Note that the back-end browse data service 110 may be considered a “dataprovider” with respect to the front-end data retrieval service 104, asthe front-end service makes requests for data to the back-end browsedata service 110 and receives data in responses provided by the back-endservice. Similarly, the one or more backing data sources 116 may beconsidered a “data provider” with respect to the back-end browse dataservice 110, as back-end browse data service 110 makes requests for datato the backing data sources 116 and receives data in responses providedby the one or more backing data sources 116.

Further note that as will be understood, a client request for dataactually may correspond to a request for a plurality of data items thatare built into a response to the client; (it is also possible to returnindividual data items for the client to build into a “response”).Similarly a request from the front-end service to the back-end servicemay comprise a single data item request or request(s) for a plurality ofdata items; this is also similar with respect to for request(s) from theback end data service to the one or more backing data sources and thecorresponding response(s). For purposes of brevity, a request for dataand corresponding data response between any two entities can beconsidered herein to include such “sub-requests” for data items and“sub-responses” that are returned, (as well as to include single dataitem request/single response operations). This terminology may beapplied herein regardless of whether and how a single request or batchedrequest may or may not be divided into separate sub-requests, and/orregardless of how a response may be built (at any level) from separatesub-responses of data items. Notwithstanding, one or more examples of arequest that corresponds to a plurality of data items are describedherein.

FIG. 2 shows additional details of a client request handling (front-end)server 206. In one or more implementations, a client request 202 isreceived at a client interface 222 of the request handling server 206.For caching purposes, the exemplified implementation includes a cacheframework 224 that accesses each cache as needed an attempt to find therequested data, starting with the lowest level cache, in-memory cacheC1(1); (the concept of “lower-level” and “higher-level” with respect tocaches as used herein is somewhat similar to CPU caches in which the L1cache is considered a lower-level cache than the L2 cache, and so on,with L1 checked before L2, and so on). If not found, the cache framework224 looks to the distributed cache 208 for the data; (note that in ormore implementations the caches may be accessed with a batch request foritems, with the lower-level cache accessed first to look for each itemof the batch of items, and for any misses at the lower level, thosemissed items looked for in the higher-level cache next, and so on). Ifagain not found, the cache framework 224 returns a cache miss, whichindicates that the request handling server 206 needs to obtain the datafrom the browse data service 110.

As described below, a request manager 228 may manage the requesting ofsuch data, including batching requests and/or multiplexing requests(e.g., sending duplicated requests only once, instead of individualrequests, and then reuniting the single response thereto with each ofthe individual requests) to avoid overloading the browse data service110.

As described herein, the request handling server 206 may similarlyrequest data from the browse data service 110 when cached data is found,but is expired in the in memory cache C1(1) and the distributed cache208. However, when expired data is found, the cache framework 224 mayreturn the expired data with some indication that the data is expired.This allows the request handling server 206 to use the expired data asdesired if the browse data service 110 is unable to return the requesteddata. As shown in FIG. 2 , cached data repurposing logic 230 is providedfor dealing with expired data. Note that the cached data repurposinglogic 230 is represented in FIG. 2 as part of the client interface 222,but may be a separate component. Indeed, in any of the figures, it isunderstood that the represented components are only examples, and thatat least some components may be combined and/or components furtherseparated into more components.

FIG. 3 shows additional details of a browse data service server 312 thathandles browse data requests 332 from a request handling server 206. Theexemplified browse data service server 312 is generally similar to therequest handling server 206 of FIG. 2 , however the cache framework 324may not return a cache miss. Instead, if requested data is not cached,or is cached but expired, the cache framework 324 or other component ofthe server 312, e.g. via a request manager 328, makes a request to thebacking data source or sources 116 to obtain the requested data. Thedata is either returned, or an error is returned.

Note that the request manager 328 may batch requests, and/or also maymultiplex requests as described herein, (although in implementations inwhich the front-end service multiplexes requests, multiplexing requestsat the back-end service may not provide benefits, as only non-duplicatedrequests need to be handled). However, in alternative implementations inwhich duplicated requests may need to be handled at the back-end,back-end request multiplexing may be performed.

FIG. 4 shows additional details of an example batch request manager 428,(which generally also applies to the request manager 328). In general,requests 402 (request 1-request j) that were not satisfied from a cacheat the request handling server level come in to the batch requestmanager 428 from requesting clients 400. Each request is associated withsome client identifier, whereby responses 418 (response 1-response j)are returned for each request 402 (request 1-request j) based upon whichclient made which request.

The batch request manager 428 is provided for efficiency, namely tohandle such requests and responses in a way that reduces the load uponthe browse data service 410. As described herein, in one or moreimplementations, efficiency is obtained by batching requests andmultiplexing requests, (although neither batching nor multiplexing is arequirement, and each may operate without the other).

Batching generally is directed towards combining multiple requests intoa single batch request instead of making individual requests, which isgenerally more efficient. To this end, batching collects requests forsome amount time, e.g., corresponding to a rendering frame, and thensends a batch request when the time is reached. The number of requestsin a batch may be limited, e.g., to sixteen or thirty-two, and thus tohandle a larger number of requests, multiple batch requests may be sentper time window, e.g., generally at the same time, but may alternativelyas soon as a batch is full.

Multiplexing generally refers to making a request for the same data onlyonce, basically filtering out duplicates. As described herein,multiplexing may be done by tracking pending requests, and only making arequest if not pending. A pending request may be considered one that hasbeen previously made and not yet received a response, including one thathas been already added to a batch waiting to be sent (if batching isbeing performed). As can be readily appreciated, because a multiplexedrequest results in a single response that has to be sent back tomultiple, different requestors, some tracking needs to be done so that amultiplexed request may be mapped back to its initiating requestor.

By way of example, consider that among the many requests handled by agiven request handling server, five different clients have made requeststhat either are in a cache miss or expired cache data condition, whichcauses a need to have the browse data service invoked. Thus, the batchrequest manager 428 multiplexes and/or batches these five requests. Aspart of multiplexing, the batch request manager 428 needs to have amapping mechanism that maintains a relationship between which requestcorresponds to which client or clients.

As a more particular example, consider that both client A and client Bhave requested some data item XYZ. The multiplexer recognizes this, andonly makes a single request for data item XYZ. However, when the singleresponse comes back with the data of data item XYZ, the mappingmechanism (which may be considered a “demultiplexer”) recognizes thatthis item applies to two different client requests, and thus that clientA needs its own response with data item XYZ, as does client B. Aresponse is thus sent for each request.

Thus, in the example implementation of FIG. 4 , multiplexing logic 442receives the requests 402, and for each request, maps a clientidentifier to the requested data item in a suitable data structure 448.For each request the multiplexing logic also checks a set of pendingrequests 446, to determine whether a request for that data item isalready pending. If so, the data item is not requested again, otherwisethe request is provided to a batching process 452.

The batching process collects such requests, and sends a set of one ormore batched requests 454 to the browse data service 410, e.g., over aconnection of network 456. The browse data service 410 returns aresponse for each request, shown as responses 458.

The responses 458 are typically not returned as a similar batch, and maycontain data items as well as error codes. Indeed, waiting for a fullset of responses to a batch request may delay all responses to theslowest one (which may be a long time), and is thus undesirable.Notwithstanding, batched responses are feasible to use, and subsets(sub-batches) of responses to a batch may be returned.

As described herein, a response may corresponds to multiple requestors,and thus a response handling process 460 (basically demultiplexinglogic) uses the client to request map 448 to provide a response for eachrequest. Note that a response may be an error message, in which eventthe cached data repurposing logic 330 (FIG. 3 ) may decide to useexpired data, if available, rather than return an error response.

FIG. 5 is similar to FIG. 4 with respect to optional multiplexing andbatching requests, and is generally not described again except to notethat the requesting entity 506 may be one or more data handling serversthat send requests to the browse data service, and also thatmultiplexing may not provide much if any benefit if front-endmultiplexing eliminates or substantially eliminates duplicate requests.Further, the batch request manager 528 may make internet requests todifferent data sources 516(1)-516(k), and thus batching may not bealways available.

FIG. 6 shows an example of a batch request manager 628 with requests fordata items (A)-(E) made by various clients. In FIG. 6 , client 602(1)makes a batch request for data items (A), (B) and (C), client 602(2)makes a get request for item D, and client 602(3) makes a batch requestfor data items (B), (C), (D) and (E). There may be other requests aswell, represents by block 602(x), however for purposes of this exampleconsider that only clients 602(1)-602(3) are making requests within thistimeframe.

The requests come into the multiplexing logic 642 of the batch requestmanager 628. As the requests are received, the multiplexing logicupdates the client to request map 648. Further, duplicate requests areremoved by checking the pending items list 646 and adding only oneinstance of each request to the list 646 and sending only one request tothe batching process 652.

At the appropriate time, e.g., once per video rendering frame, thebatching process sends a batch request for items (A), (B), (C), (D) and(E) to the browse data service 610. The browse data service 610 returnsdata from one of its caches when cached, or attempts to obtain the datafrom one or more data stores if not cached. Again, cached but expireddata may be returned instead of an error, if such data exists. Note thatthe responses are not batched in this example, and may be returned inany order, e.g., responses for data items (B), (C), (E), (D) and (A) arereturned in the example of FIG. 6 .

Any of these data items may be an error response rather than the actualdata item. Because all the way data items are built and cached, they arenot independent of one another in one or more implementations. In suchimplementations, an error message with respect to any one of a group ofdata items requested together may cause the entire request to fail. Ifavailable, expired data may be returned instead of a failure message,with some indication that the data is expired.

As described herein, these responses, which were multiplexed, need to bemapped back to their requesting clients. This is performed by theresponse handling process 660, using the map 648 to build a response foreach client. Note that a response to each client may not be batched, butreturned as received, basically in a “stream” of responses. Further, asdescribed herein, cached data repurposing logic 612 may decide to useexpired data rather than an error message for any error returned in aresponse.

FIG. 7 is a flow diagram showing example steps that may be taken bycached data repurposing logic of a request handling server (e.g. 106 (1)of FIG. 1 ) of the data retrieval service 104 (FIG. 1 ). Step 702represents receiving a request from a client for data. Step 704evaluates whether the data is found in a cache of the data retrievalservice level. If not, step 704 branches to FIG. 8 (described below) torequest the data from the browse data service.

If found in a cache, step 706 evaluates whether the data is expired.Note that if the data was found in the in memory cache, and was expired,the cache framework also looks to the distributed cache to see ifunexpired data is present. Unexpired data is used when available. If notexpired at step 706, step 708 returns the cached, unexpired data in aclient response.

If expired, the data may be available from the back-end browse dataservice. However, the time it takes to obtain the data may beundesirable, and thus step 710 represents starting a timer so that theamount of time can be evaluated, as well as making the request(s) to theback-end data service. Step 712 represents building the requested datafrom the data services, e.g., as the requested data comes in. Note thatthe request for data may correspond to multiple data items requested ina batch request, or possibly via separate requests.

The building continues at step 712 as data items are received from thebrowse data service until done as evaluated at step 714, or an error ortimeout occurs as evaluated at step 720. If the building of the responseis done successfully, step 716 responds with the data. Step 718 savesthe data to the caches via the cache framework.

If the data is unavailable whether because an error is returned or thebuilding operation times out as evaluated at step 720, the expired datais returned instead of an error message at step 722. For a timeoutsituation, although expired data was returned to one or more requestingclients, the request handling server will continue to build the data(e.g., for anticipated future requests), and will cache the data ifsuccessfully built. If an error is returned, the request handling servermay attempt to re-request the data, although this may depend upon thetype of error.

As described herein, the browse data service also may be configured toreturn expired data instead of an error message, in which event therequest handling server may choose to use that expired data. Indeed, theexpired data from the browse data service back-end level maybe fresherthan the expired data from the caches at the data retrieval servicefront-end level, and the expiration times, if different, may be used todecide which set of expired data to use.

FIG. 8 represents calling the browse data service when no cache dataincluding any expired data was found by the request handling server(e.g., its cache framework). As can be readily appreciated, a differenceof FIG. 8 from step 710's branch is that there is not any expired datato potentially use, in which event the data that satisfies the requestneeds to be built or an error returned.

Step 802 starts a timeout timer, which may be a different amount oftimeout time from that with reference to steps 710 and 720 of FIG. 7 .For example, it may be more desirable to wait longer when there is noexpired data available at the front-end, as opposed to returning expireddata when available at the front-end. Step 802 also represents makingthe request(s) to the back-end data service

Step 804 represents building the requested data as data items arereceived from the browse data service, which continues until done asevaluated at step 806, an error is detected at step 812 or the timerreaches the timeout time at step 816. If done successfully, step 808responds with the built data, and step 810 saves it to the caches, e.g.via the cache framework. Note that the data returned from the browsedata service may be expired data from a cache at the browse data servicelevel.

If an error is detected at step 812 while receiving the data items forbuilding the response, then in one or more implementations an errorneeds to be returned in the response. If a timeout occurs as evaluatedat step 816, then an error also needs to be returned, however thetimeout error message may be different from the error message for anerror. Note that the timeout time may be longer than the time that thebrowse data service uses to return expired data if retrieving the datafrom the data sources is taking too long.

FIGS. 9 and 10 are directed to operations performed by the browse dataservice upon receiving a request for data. As described herein, thebrowse data service also maintains caches for responding to requests.Note that FIG. 9 assumes a first level and second level cache, however(as with the front-end service) there may be no caches, one cache or upto any practical number of caches at the browse data service level.

Thus, upon receiving a request at step 902, step 904 evaluates whetherthe request may be satisfied by data in the first cache. If so, step 904branches to step 906 which checks whether the data is expired. If not,step 906 branches to step 916 where the data is returned for thisrequest. If found at step 904 but expired at step 906, step 908 holdsthe expired data. This allows the expired data to be returned if thedata item(s) comprising the request are unable to be retrieved from thedata source(s). Note that step 908 may be bypassed if it is certain thatthis same data or a fresher copy of this data is in the second cache.

If not found in the first cache or found but expired, step 910 looks forthe data in the second cache. If found in the second cache, step 912similarly is performed to determine whether the data is expired. If not,the data it found in the second cache is used to update the first cacheat step 914, and step 916 returns the data.

It should be noted that an emergency mode may be used when it is knownthat the browse data service will be unable to return a requested dataitem from a data source. For example, if it is known that a significantbacking data source is down, then making the request to that backingdata source is pointless. This may be detected by a flood of errormessages, for example, which may be used to automatically turn theemergency mode on, or the emergency mode may be manually turned on by anadministrator or the like. It is also feasible to notify the front-endservice of the emergency mode and let the front-end data service use anycached, expired data directly, although this means that expired data isreturned even when the back-end data service has non-expired cacheddata. Still further, if the front-end data service is unable tocommunicate with the back-end data service, the front-end data servicemay operate in its own, similar emergency mode in which expired data isreturned without attempting to obtain data from the back-end dataservice.

In general, when in the emergency mode, if cached, the requested data isreturned from a cache, whether expired or not. For example, if expired,the data from the second cache (which is ordinarily the same or fresher)is returned rather than expired data from the first cache, (however itis feasible to simply use expired data from the first cache while inemergency mode without even accessing the second cache, provided suchdata exists).

Thus, if found but expired, step 918 determines whether the service isin the emergency mode, and if so step 916 returns the expired data. Ifnot in the emergency mode then step 920 holds the expired data. Notethat the expired data from the second cache may overwrite any previouslyheld expired data from the first cache, as data in the second cache is(normally) fresher than or the same as data in the first cache. If thisis not certain, however, the fresher of the two may be used, forexample, which is one reason why step 908 may be used to hold the data.

If no data is cached as determined by step 910, and in the emergencymode as determined at step 922, then an error is returned at step 924.Note that this assumes that the second cache includes any data thatexists in the first cache, (because the second cache is ordinarilylarger and write through operations occur to each cache and so on). Ifthis is not certain, then instead of directly returning an error, acheck (not shown in FIG. 9 ) may be first made as to whether expireddata is being held (via step 908) from the first cache, and if so, thatheld data is returned instead of the error at step 924.

If not in the emergency mode, and if no data is cached or only expireddata was cached, the steps continue to FIG. 10 to retrieve the data itemor items corresponding to the request.

Step 1002 of FIG. 10 represents breaking the data requests into one ormore data item requests. Step 1004 determines the source for each dataitem request and sends a request to the source corresponding to the dataitem. For example, the browse data service knows from which data sourceto request images for an image data item, text for a movie description,and so on, and any of these may be different data sources. Requests tothe same data source may be batched; it is also feasible to batchrequests to different data sources in a batch request if a downstreamentity is present that can separate the individual requests.

Step 1006 waits for a response to be received. When received, step 1008evaluates whether the response is an error message. If not, step 1010returns the response. Step 1012 evaluates whether more responses aredue, that is, whether one or more requests for data items are stilloutstanding. If so, step 1012 returns to step 1006 to wait for the nextresponse, otherwise the data items have all been returned and theprocess completes.

If an error was received at step 1008, then no complete response may bereturned in one or more implementations. Note however that alternativeimplementations may allow individual data items to be returned and usedin a partial response, possibly combined with expired data to provide afull response.

Because in this example an error in retrieving any data item means thatthe entire request failed, step 1014 attempts to return expired datainstead, that is, if expired data exists (e.g., held at step 908 or step914 of FIG. 9 ). If expired data exists, step 1016 returns the expireddata, possibly along with an error message or other error code toprovide the data retrieval service with more context as to why expireddata was returned. For example, a timeout error may be returned, inwhich event the data retrieval service may re-request the data, whereasa message indicating that no such data exists (e.g., the requested dataitem has been removed from a database) may not be re-requested. If anerror is returned as detected at step 1008 and no expired data exists asevaluated at step 1014, then step 1018 returns an error.

As can be seen, the general actions are to return cached, unexpired datawhen such data exists in response to a request. If cached, unexpireddata is not present at a front-end service, then an attempt to obtainthe requested data from a data service (e.g., a back-end service) ismade. If the attempt is successful, the requested data is returned. Ifthe requested data is unavailable (e.g., the attempt fails because of anerror or is taking too long), when present expired data may berepurposed and returned in a response. Thus, returning an error messageoften can be avoided. An emergency mode may be provided in which data isreturned from a cache when such data exists, whether expired or not,otherwise an error message is returned.

One or more aspects are directed towards receiving a client request forclient-requested data, and accessing a cache set to attempt to locatethe client-requested data. If the data is in the cache set and is notexpired data, the data is returned from the cache set in response to theclient request. If the data is in the cache set and is expired data, theexpired data is maintained and the data is requested from a dataprovider. If the requested data is available from the data provider, thedata is received from the data provider and is returned in response tothe client request. If the data is not available from the data provider,the expired data is returned in response to the client request.

When the data is not in the cache set, the data is requested from thedata provider, the data is determined to be not available from the dataprovider, an error response may be returned in response to the clientrequest. When the data is in the cache set and is expired, the data maybe determined to be not available from the data by receiving an errorresponse from the data provider, or by reaching a timeout expirationtime without the requested data having been returned by the dataprovider. When the data is in the cache set and is expired, and the datacorresponds to a plurality of data items, the data may be determined tobe not available from the data provider based upon reaching a timeoutexpiration time without having received each data item of the pluralityof data items within the timeout expiration time. When the data is inthe cache set and is expired, and the data corresponds to a plurality ofdata items, the data may be determined to be not available from the dataprovider based upon receiving an error message in response to a requestfor any of the plurality of data items.

Requesting the data from the data provider may include communicating arequest from a front-end service that includes the cache set to a backend data service comprising the data provider. Expired data from theback-end data service (comprising the data provider) may be received inresponse to the request from the front-end data service to the back-enddata service; the expired data received at the front-end data servicemay be returned in response to the client request.

Requesting the data from the data provider may include communicating arequest from a back-end service that includes the cache set to at leastone backing data source comprising the data provider

One or more aspects are directed towards a front-end data service thatis coupled to communicate with a back-end data service, and is alsocoupled to communicate with client requesters, including to receive aclient request for data. The front-end data service includes a front-endcache set that is accessed for the request to determine if cached dataexists in the front-end cache set to use in a response to the clientrequest for data. If cached data exists in the front-end cache set andthe cached data is not expired, the front-end data service uses the datafrom the front-end cache set in the response to the client request fordata. If cached data does not exist in the front-end cache set, thefront-end data makes a front-end service request for the data to theback-end data service, and if data is returned from the back-end dataservice in a back-end response to the front-end service request, thefront-end data service uses the data returned from the back-end dataservice in the response to the client request for data. If cached dataexists in the front-end cache set, and the cached data is expired cacheddata, the front-end data service makes a front-end service request forthe data to the back-end data service, and if the data is not availablefrom the back-end data service, the front-end data service uses theexpired cached data from the front-end cache set in response to theclient request for data.

If cached data does not exist in the front-end cache set, and the datais not available from the back-end data service, the front-end servicemay return an error in response to the client request.

The front-end cache set may include a single cache, or at least twocaches in a tiered cache configuration.

The back-end data service may include a back-end cache set, and whendata is requested from the back-end data service by the front-end dataservice, the back-end data service may determine if cached data for thefront-end service request exists in the back-end cache set; if cacheddata exists in the back-end cache set, and the cached data is notexpired, the back-end data service uses the data from the back-end cacheset in a response to the front-end service request. If cached data doesnot exist in the back-end cache set, the back-end data servicecommunicates with one or more backing data sources to make one orback-end service requests for the data to the one or more backing datasources; if the data is returned from the one or more backing datasources in one or more responses to the one or more back-end servicerequests, the back-end data service uses the data in a response to thefront-end service request. If cached data exists in the back-end cacheset and is expired, the back-end data service communicates with one ormore backing data sources to make one or back-end service requests forthe data to the one or more backing data sources; if the data is notavailable from the one or more backing data sources, the back-end dataservice uses the expired data in a response to the front-end servicerequest.

The back-end data service may include a back-end cache set, and theback-end data service may operate in an emergency mode. When data isrequested from the back-end data service by the front-end data service,the back-end data service may determine if cached data for the front-endservice request exists in the back-end cache set; if cached data existsin the back-end cache set, the back-end data service may use the datafrom the back-end cache set in a response to the front-end servicerequest independent of whether the data in the back-end cache set isexpired or not expired.

The front-end data service may include a batch manager that batchesrequests to the back-end data service. The front-end data service mayinclude a request multiplexer that multiplexes requests to the back-enddata service and demultiplexes responses from the back-end data service.

One or more aspects are directed towards receiving a client request fordata at a front-end data service, and accessing a front-end cache set toattempt to obtain the data. If obtained from the front-end cache set, adetermination is made as to whether the data is expired; if not expired,the data is used in a response to the client. If expired, the expireddata is maintained, and an attempt is made to obtain the data bycommunicating with a back-end data service; if the data is availablefrom the back-end data service, the data is used in a response to theclient. If the data is not available from the back-end data service, andexpired data is maintained the expired data is used in a response to theclient. If the data is not available from the back-end data service andno expired data is maintained, an error message is provided in aresponse to the client.

The determination may be made that the data is not available from theback-end data service by reaching a timeout time before the back-enddata service has returned the data or by receiving an error message fromthe back-end data service. The data requested from the back-end dataservice may include a plurality of sub-requests, and determining thatthe data is not available from the back-end data service may includereaching a timeout time before the back-end data service has returned adata item response for each sub-request, or may include receiving anerror message from the back-end data service for any sub-request.

Communicating with the back-end data service to attempt to obtain thedata may include sending a front-end data service request to theback-end data service and receiving the front-end data service requestfor data at the back-end data service. A back-end cache set to may beaccessed to attempt to obtain the data, and if obtained from theback-end cache set and if not expired, the data may be used in aback-end response to the front-end data service request. If expired, theexpired data may be maintained. One or more backing data sources may becommunicated with to attempt to obtain the data, and if the data isavailable from the one or more backing data sources, the data may beused in a back-end response to the front-end data service. If the datais not available from the front-end data service request and expireddata is maintained, the expired data may be used in a back-end responseto the front-end data service request. If the data is not available fromthe one or more backing data sources and no expired data is maintained,an error message may be provided in a back-end response to the front-enddata service request.

Communicating with the back-end data service to attempt to obtain thedata may include sending a front-end data service request to theback-end data service. The back-end data service may be operated in anemergency mode, including receiving the front-end data service requestfor data at the back-end data service, accessing a back-end cache set toattempt to obtain the data, and if obtained from the back-end cache set,returning the data from the back-end cache set in response to thefront-end data service request. If not obtained from the back-end cacheset, an error message may be returned in response to the front-end dataservice request.

Example Computing Device

The techniques described herein can be applied to any device or set ofdevices (machines) capable of running programs and processes. It can beunderstood, therefore, that personal computers, laptops, handheld,portable and other computing devices and computing objects of all kindsincluding cell phones, tablet/slate computers, gaming/entertainmentconsoles and the like are contemplated for use in connection withvarious implementations including those exemplified herein. Accordingly,the general purpose computing mechanism described below in FIG. 11 isbut one example of a computing device.

Implementations can partly be implemented via an operating system, foruse by a developer of services for a device or object, and/or includedwithin application software that operates to perform one or morefunctional aspects of the various implementations described herein.Software may be described in the general context of computer executableinstructions, such as program modules, being executed by one or morecomputers, such as client workstations, servers or other devices. Thoseskilled in the art will appreciate that computer systems have a varietyof configurations and protocols that can be used to communicate data,and thus, no particular configuration or protocol is consideredlimiting.

FIG. 11 thus illustrates an example of a suitable computing systemenvironment 1100 in which one or aspects of the implementationsdescribed herein can be implemented, although as made clear above, thecomputing system environment 1100 is only one example of a suitablecomputing environment and is not intended to suggest any limitation asto scope of use or functionality. In addition, the computing systemenvironment 1100 is not intended to be interpreted as having anydependency relating to any one or combination of components illustratedin the example computing system environment 1100.

With reference to FIG. 11 , an example device for implementing one ormore implementations includes a general purpose computing device in theform of a computer 1110. Components of computer 1110 may include, butare not limited to, a processing unit 1120, a system memory 1130, and asystem bus 1122 that couples various system components including thesystem memory to the processing unit 1120.

Computer 1110 typically includes a variety of machine (e.g., computer)readable media and can be any available media that can be accessed by amachine such as the computer 1110. The system memory 1130 may includecomputer storage media in the form of volatile and/or nonvolatile memorysuch as read only memory (ROM) and/or random access memory (RAM), andhard drive media, optical storage media, flash media, and so forth. Byway of example, and not limitation, system memory 1130 may also includean operating system, application programs, other program modules, andprogram data.

A user can enter commands and information into the computer 1110 throughone or more input devices 1140. A monitor or other type of displaydevice is also connected to the system bus 1122 via an interface, suchas output interface 1150. In addition to a monitor, computers can alsoinclude other peripheral output devices such as speakers and a printer,which may be connected through output interface 1150.

The computer 1110 may operate in a networked or distributed environmentusing logical connections to one or more other remote computers, such asremote computer 1170. The remote computer 1170 may be a personalcomputer, a server, a router, a network PC, a peer device or othercommon network node, or any other remote media consumption ortransmission device, and may include any or all of the elementsdescribed above relative to the computer 1110. The logical connectionsdepicted in FIG. 11 include a network 1172, such as a local area network(LAN) or a wide area network (WAN), but may also include othernetworks/buses. Such networking environments are commonplace in homes,offices, enterprise-wide computer networks, intranets and the Internet.

As mentioned above, while example implementations have been described inconnection with various computing devices and network architectures, theunderlying concepts may be applied to any network system and anycomputing device or system in which it is desirable to implement suchtechnology.

Also, there are multiple ways to implement the same or similarfunctionality, e.g., an appropriate API, tool kit, driver code,operating system, control, standalone or downloadable software object,etc., which enables applications and services to take advantage of thetechniques provided herein. Thus, implementations herein arecontemplated from the standpoint of an API (or other software object),as well as from a software or hardware object that implements one ormore implementations as described herein. Thus, various implementationsdescribed herein can have aspects that are wholly in hardware, partly inhardware and partly in software, as well as wholly in software.

The word “example” is used herein to mean serving as an example,instance, or illustration. For the avoidance of doubt, the subjectmatter disclosed herein is not limited by such examples. In addition,any aspect or design described herein as “example” is not necessarily tobe construed as preferred or advantageous over other aspects or designs,nor is it meant to preclude equivalent example structures and techniquesknown to those of ordinary skill in the art. Furthermore, to the extentthat the terms “includes,” “has,” “contains,” and other similar wordsare used, for the avoidance of doubt, such terms are intended to beinclusive in a manner similar to the term “comprising” as an opentransition word without precluding any additional or other elements whenemployed in a claim.

As mentioned, the various techniques described herein may be implementedin connection with hardware or software or, where appropriate, with acombination of both. As used herein, the terms “component,” “module,”“system” and the like are likewise intended to refer to acomputer-related entity, either hardware, a combination of hardware andsoftware, software, or software in execution. For example, a componentmay be, but is not limited to being, a process running on a processor, aprocessor, an object, an executable, a thread of execution, a program,and/or a computer. By way of illustration, both an application runningon a computer and the computer can be a component. One or morecomponents may reside within a process and/or thread of execution and acomponent may be localized on one computer and/or distributed betweentwo or more computers.

The aforementioned systems have been described with respect tointeraction between several components. It can be appreciated that suchsystems and components can include those components or specifiedsub-components, some of the specified components or sub-components,and/or additional components, and according to various permutations andcombinations of the foregoing. Sub-components can also be implemented ascomponents communicatively coupled to other components rather thanincluded within parent components (hierarchical). Additionally, it canbe noted that one or more components may be combined into a singlecomponent providing aggregate functionality or divided into severalseparate sub-components, and that any one or more middle layers, such asa management layer, may be provided to communicatively couple to suchsub-components in order to provide integrated functionality. Anycomponents described herein may also interact with one or more othercomponents not specifically described herein but generally known bythose of skill in the art.

In view of the example systems described herein, methodologies that maybe implemented in accordance with the described subject matter can alsobe appreciated with reference to the flowcharts/flow diagrams of thevarious figures. While for purposes of simplicity of explanation, themethodologies are shown and described as a series of blocks, it is to beunderstood and appreciated that the various implementations are notlimited by the order of the blocks, as some blocks may occur indifferent orders and/or concurrently with other blocks from what isdepicted and described herein. Where non-sequential, or branched, flowis illustrated via flowcharts/flow diagrams, it can be appreciated thatvarious other branches, flow paths, and orders of the blocks, may beimplemented which achieve the same or a similar result. Moreover, someillustrated blocks are optional in implementing the methodologiesdescribed herein.

CONCLUSION

While the invention is susceptible to various modifications andalternative constructions, certain illustrated implementations thereofare shown in the drawings and have been described above in detail. Itshould be understood, however, that there is no intention to limit theinvention to the specific forms disclosed, but on the contrary, theintention is to cover all modifications, alternative constructions, andequivalents falling within the spirit and scope of the invention.

In addition to the various implementations described herein, it is to beunderstood that other similar implementations can be used ormodifications and additions can be made to the describedimplementation(s) for performing the same or equivalent function of thecorresponding implementation(s) without deviating therefrom. Stillfurther, multiple processing chips or multiple devices can share theperformance of one or more functions described herein, and similarly,storage can be effected across a plurality of devices. Accordingly, theinvention is not to be limited to any single implementation, but ratheris to be construed in breadth, spirit and scope in accordance with theappended claims.

What is claimed is:
 1. A system, comprising: a processor; and a memorythat stores executable instructions that, when executed by theprocessor, facilitate performance of operations, the operationscomprising: receiving a client request for a data item, and in responseto the client request: accessing a cache set to attempt to locate acache entry corresponding to the data item; in response to locating anunexpired cache entry corresponding to the data item, returning the dataitem, corresponding to the unexpired cache entry, from the cache set inresponse to the client request; and in response to locating an expiredcache entry corresponding to the data item, maintaining the expiredcache entry and requesting the data item from a data provider, whereinin response to the requested data item being returned by the dataprovider, returning the data item from the data provider in response tothe client request, and in response to indication of operation of anemergency mode related to the cache set or the data provider and therequested data item not being returned, returning data comprising theexpired cache entry.
 2. The system of claim 1, wherein the data itemcorresponds to an expired entry in the cache set, and wherein the dataitem is not returned by the data provider within a timeout time.
 3. Thesystem of claim 1, wherein the data item corresponds to an expired entryin the cache set, wherein the data item is not returned by the dataprovider, and wherein the operations further comprise, returning anerror response in conjunction with returning the data comprising theexpired cache entry, in response to the client request.
 4. The system ofclaim 1, wherein the data item corresponds to an expired entry in thecache set, wherein the data item is not returned by the data provider,and wherein the operations further comprise receiving an error responsefrom the data provider.
 5. The system of claim 1, wherein requesting thedata from the data provider comprises communicating a request from afront-end service that includes the cache set to a back-end data servicecomprising the data provider.
 6. The system of claim 5, wherein theoperations further comprise, receiving an expired data item from theback-end data service, and returning the expired data item in responseto the client request.
 7. The system of claim 1, wherein the data itemcorresponds to an expired entry in the cache set, wherein the data itemis returned as an unexpired data item by the data provider, and whereinthe operations further comprise updating the cache set with theunexpired data item returned by the data provider.
 8. The system ofclaim 1, wherein the data item is not located in the cache set, andwherein the operations further comprise requesting the data item from adata provider, and in response to the requested data item being returnedby the data provider, returning the data item from the data provider inresponse to the client request, and in response to the requested dataitem not being returned by the data provider, returning an error, inconjunction with returning the data comprising the expired cache entry,in response to the client request.
 9. The system of claim 1, wherein theoperations further comprise indicating a back-end data servicecomprising the data provider as operating in the emergency modecomprising a non-responsive state.
 10. The system of claim 1, whereinthe operations further comprise indicating a front-end data servicecomprising the cache set as operating in the emergency mode due toinability to communicate with a back-end data service comprising thedata provider.
 11. A system, comprising: a processor; and a memory thatstores executable instructions that, when executed by the processor,facilitate performance of operations, the operations comprising:receiving, at a server, a client request for data; determining whetherthe data exists as cached data in a cache set coupled to the server; andin response to determining that the data exists as cached data in thecache set and the cached data is not expired, returning the cached datafrom the cache set in response to the client request for data; inresponse to determining that the data does not exist as cached data inthe cache set, requesting the data from a data service, and if the datais returned from the data service, returning the data returned from thedata service in response to the client request for data; and in responseto determining that the data exists as cached data and the cached datais expired cached data, requesting the data from the data service, andin response to a front-end data service comprising the cache set or aback-end data service comprising the data service being in anon-responsive state, returning data comprising the expired cached datain response to the client request for data.
 12. The system of claim 11,wherein the cache set comprises a single cache, or wherein the cache setcomprises at least two caches in a tiered cache configuration.
 13. Thesystem of claim 11, wherein the cache set comprises a local cache of theserver, and a distributed cache coupled to the server and at least oneother server.
 14. The system of claim 13 wherein the back-end dataservice is coupled to a back-end cache set, and wherein when the data isrequested from the back-end data service by the front-end data retrievalservice, the back-end data service determines if back-end cached datafor the front-end service request exists in the back-end cache set, andif back-end cached data exists in the back-end cache set, and the cacheddata is not expired, the back-end data service uses the back-end cacheddata from the back-end cache set in a response to the front-end servicerequest; if back-end cached data does not exist in the back-end cacheset, the back-end data service communicates with one or more backingdata sources to make one or back-end service requests for the data tothe one or more backing data sources, and if the data is returned fromthe one or more backing data sources in one or more responses to the oneor more back-end service requests, the back-end data service uses thedata in a response to the front-end service request; or if back-endcached data cached data exists in the back-end cache set and is expired,the back-end data service communicates with one or more backing datasources to make one or back-end service requests for the data to the oneor more backing data sources, and if the data is not available from theone or more backing data sources, the back-end data service uses theexpired back-end cached data in a response to the front-end servicerequest.
 15. The system of claim 11, wherein the operations furthercomprise indicating operation of an emergency mode in response toreceipt of a plurality of error messages from a back-end data servicecomprising the data service.
 16. A non-transitory machine-readablemedium, comprising executable instructions that, when executed by aprocessor, facilitate performance of operations, the operationscomprising: receiving a client request for data at a front-end dataservice; accessing a front-end cache set to attempt to obtain the data;if the data is obtained from the front-end cache set, determiningwhether the data is expired, and if the data is not expired, using thedata in a response to the client request, and if the data is expired,maintaining the expired data, communicating with a back-end data serviceto attempt to obtain the data, and if the data is returned from theback-end data service, using the data in a response to the clientrequest, and if the data is not available from the back-end dataservice, returning data comprising the expired data in a response to theclient request, and if the data is not obtained from the front end cacheset, communicating with a back-end data service to attempt to obtain thedata, and if the data is returned from the back-end data service, usingthe data in a response to the client request, and if the data is notreturned from the back-end data service and the back-end data service isin a non-responsive state, providing an error message and the expireddata in a response to the client request.
 17. The non-transitorymachine-readable medium of claim 16, wherein the operations furthercomprise, at the back end data service, receiving a communication fromthe front-end data service attempting to obtain the data, accessing aback-end cache set to attempt to obtain the data, and if obtained fromthe back-end cache set, determining whether the data is expired, and ifnot expired, using the data in a back-end response to the front-end dataservice communication, and if expired, communicating with one or morebacking data sources to attempt to obtain the data, and if the data isreturned by the one or more backing data sources, using the data in aback-end response to the front-end data service communication, and ifthe data is not returned by the one or more backing data sources, usingthe expired data in a back-end response to the front-end data servicecommunication; and if not obtained from the back-end cache set,communicating with one or more backing data sources to attempt to obtainthe data, and if the data is returned by the one or more backing datasources, using the data in a back-end response to the front-end dataservice communication, and if the data is not returned by the one ormore backing data sources, providing an error message in a back-endresponse to the front-end data service request.
 18. The non-transitorymachine-readable medium of claim 16, wherein the operations furthercomprise determining that the data is not returned from the back-enddata service, comprising reaching a timeout time before the back-enddata service has returned the data, or receiving an error message fromthe back-end data service.
 19. The non-transitory machine-readablemedium of claim 16, wherein the data is obtained from the front-endcache set, wherein the data is expired, wherein the data is returnedfrom the back-end data service to the front-end data service, andwherein the operations further comprise updating the front-end cache setwith the data returned from the back end data service.
 20. Thenon-transitory machine-readable medium of claim 16, wherein theoperations further comprise indicating operation of an emergency mode ofthe back-end data service in response to receipt of a plurality of errormessages from the back-end data service.